Some application developers develop applications which perform data storage and retrieval operations. To this end, an application developer typically writes application source code which includes data storage and/or retrieval commands using a programming language (e.g., the C programming language). In general, the application developer builds an executable application from the application source code (e.g., by compiling and linking the application source code). This executable application contains instructions that run on a computer system to store data within and/or retrieve data from memory of the computer system.
By way of example, FIG. 1 shows a computer system 20 which includes a first computer 22-A, a second computer 22-B, and a network connection 24 allowing communication between the first and second computers 22-A, 22-B. Each of the first and second computers 22-A, 22-B includes a filesystem. In particular, the first computer 22-A includes a UNIX filesystem 26-A. Similarly, the second computer 22-B includes a UNIX filesystem 26-B. As shown in FIG. 1, each of the UNIX filesystems 26-A, 26-B includes files which are logically organized in an inverted tree configuration.
The second computer 22-B further includes a directory system. In particular, as shown in FIG. 1, the second computer 22-B has a Lightweight Directory Access Protocol (LDAP) directory system 28-B and operates as an LDAP server. The LDAP directory system 28-B includes directory entries which are organized in an inverted tree configuration which is similar to that of the UNIX filesystems 26-A, 26-B. Directory systems are similar to databases in that they operate as repositories, or storage facilities, for information. However, in contrast to databases, directory systems tend to contain more descriptive, attribute-based information (e.g., names, addresses, job titles, etc.). Furthermore, information is generally more often read from such directory systems than written to such directory systems.
FIG. 2A shows application code 30 having commands for accessing the filesystem 26-A of the first computer 22-A. In particular, the application code 30, when compiled and linked into an executable application, provides instructions for retrieving information 32 from a file 34 of the filesystem 26-A.
To create application code for accessing UNIX filesystems, application developers can use file access commands in the C programming language. In general, such commands have standardized names (e.g., xe2x80x9copen( )xe2x80x9d, xe2x80x9cwrite( )xe2x80x9d, xe2x80x9cread( )xe2x80x9d, xe2x80x9cgetline( )xe2x80x9d, xe2x80x9cclose( )xe2x80x9d, etc.) and standardized expression formats (e.g., operation(arg1, . . . ,argN)).
Some application developers develop applications which conform to a programming standard called POSIX, which is an acronym for portable operating system interface for computer environments. By conforming application code to the POSIX programming standard, the application developer has some assurance that the application will be relatively easily portable to POSIX-compliant computer systems. Sun Microsystems, Inc. of Palo Alto, Calif., International Business Machines Corporation of Armonk, N.Y., and Hewlett-Packard of Palo Alto, Calif. are examples of computer manufacturers which provide POSIX-compliant computer systems.
It should be understood that there are other filesystems which can be used for storing and retrieving data. Examples of other filesystems include the MS-DOS filesystem and the Windows/NT filesystem, both of which are provided by Microsoft Corporation of Redmond, Wash.
Furthermore, it should be understood that some computer systems provide access to multiple types of filesystems. For example, some computer systems running the UNIX operating system can be configured to provide access to both a UNIX filesystem and a Windows/NT filesystem. In general, when applications run in such a computer system, the operating system handles application instructions (e.g., system calls) which request access to files of the different filesystems. Typically, when a running application reaches a file access instruction (e.g., open( )), the operating system figures out which type of filesystem the file access instruction is attempting to access (i.e., UNIX or Windows/NT in this example), and then performs one or more file access operations which are appropriate for accessing that type of filesystem.
FIG. 2B shows application code 40 having commands for accessing the LDAP directory system 28-B of the second computer 22-B (an LDAP server). In particular, the application code 40, when compiled and linked into an executable application, provides instructions for retrieving information 42 from an LDAP directory entry 44 of the LDAP directory system 28-B. Generally, the computer system 52-B operates as an LDAP server such that an executable application derived from the application code 40 can run on any of the computers 22 as an LDAP client communicating with the LDAP server.
To create application code for accessing directory systems, an application developer typically obtains a development environment package from a provider or manufacturer of a directory system product (hereinafter referred to as a vendor). Such a package typically includes a vendor-specific application programming interface (API) for developing an application, and a directory system server platform having a suite of services, utilities and tools for testing the application. In general, the application developer includes, in the application code, directory access commands (e.g., xe2x80x9cldap_search( )xe2x80x9d, xe2x80x9cldap_entry( )xe2x80x9d, xe2x80x9cIdap_first_attribute( )xe2x80x9d, xe2x80x9cldap_next13 attribute( )xe2x80x9d, etc.) which conform to the vendor-specific API. In the case of LDAP directory systems, such code typically relies on manipulating LDAP information such as directory entry locations, port numbers, etc.
Additionally, it is common for such commands to have unique, vendor-specific names and expressions. Examples of LDAP directory system vendors include the University of Michigan of Ann Arbor, Mich., Sun Microsystems, Inc. of Palo Alto, Calif., International Business Machines Corporation of Armonk, N.Y., and Netscape Communications Corporation of Mountain View, Calif. By way of example, the command for performing a bind function using ADSI, which is provided by Microsoft Corporation of Redmond, Wash., is similar to:
AdsOpenObject(xe2x80x9cLDAP://server/en=bols,o=company . . . ).
In contrast, the command for performing a bind function using NDS, which is provided by Novell of Orem, Utah, is similar to:
NWDSLogin(context,o,UserName,UserPassword,o).
Accordingly, LDAP expressions can vary greatly among vendors.
Applications which access directory systems using vendor-specific APIs are often hindered by unique aspects of such APIs. For example, it is common for LDAP vendors to require unique names and expressions for particular LDAP commands. That is, application developers must use these unique names and expressions in order to properly program an application to a particular LDAP vendor""s API. Accordingly, the application developer of an application often relies on each customer having a particular LDAP server product also installed on computer systems running the application developer""s application. Otherwise, it may be possible for the application to include one or more LDAP commands (e.g., ldap_open( ), ldap_create( ), ldap_read( ), etc.) or command expressions (e.g., Idap_open(arg1,arg2) vs. Idap_open(*argl,*arg2)) which the computer system cannot understand or handle.
In situations where the LDAP product of a particular LDAP vendor is unavailable but the LDAP product of another LDAP vendor is available, the application developer may be able to port the LDAP application such that it is able to use the other LDAP product. However, in some situations, applications are not easily portable and require significant code changes when switching between different vendor-specific APIs. Furthermore, if even only minor code changes are required, the porting process still requires recompiling and relinking of the application, and often thorough retesting. Moreover, such an endeavor often requires that the application developer provide future technical support for both the original application (which works with the original vendor-specific API) as well as any newly ported application (which works with the new vendor-specific API) in order to maintain goodwill, and the perception of quality and good service among customers.
In contrast to the above-identified approaches to accessing LDAP directory systems using different vendor-specific APIs, the invention is directed to techniques for accessing a data storage system having both a filesystem and directory system by determining, in response to an instruction for accessing a portion of the data storage system, whether the portion is a file of the filesystem or a directory entry of the directory system, and then accessing that portion of the data storage system appropriately. Accordingly, application developers can use commands with common or standard names and expressions, such as those for accessing files of filesystems (e.g., POSIX calls), and rely on the above-identified determination (e.g., performed by the operating system of a computer) for proper operation and processing of the application.
One arrangement of the invention is directed an apparatus having memory that stores an application, and a controller that is coupled to the memory. The controller operates in accordance with the application stored in the memory to access a data storage system. The data storage system includes a filesystem and a directory system. The application configures the controller to perform a method having the steps of: (a) obtaining an access instruction which identifies a portion of the data storage system, and (b) determining, in response to the obtained access instruction, whether the identified portion of the data storage system is a file of the filesystem or a directory entry of the directory system. The method further includes the step of: (c) performing a file access operation to access the identified portion as a file when the identified portion is determined to be a file of the filesystem, and a directory entry access operation to access the identified portion as a directory entry when the identified portion is determined to be a directory entry of the directory system.
Since the apparatus is capable of determining whether the access instruction identifies a file of a filesystem or a directory entry of a directory system, application developers need not be concerned about the availability of any particular vendor-specific APIs. Rather, the application developers can simply use an access instruction with a common syntax and expression such as that for accessing a file of filesystem (e.g., open( ), read( ), write( ), etc.), and let the apparatus (e.g., specialized hardware, a computer, etc.) determine how to handle such instructions.
In one arrangement, the filesystem is a UNIX filesystem, and the directory system is a Lightweight Directory Access Protocol directory system. In this arrangement, the step of performing includes the step of accessing the identified portion of the data storage system as (i) a UNIX file when the identified portion is determined to be a file of the filesystem, or (ii) a Lightweight Directory Access Protocol (LDAP) directory entry when the identified portion is determined to be a directory entry of the directory system.
In one arrangement, the method further includes, prior to the step of performing the access operation, the step of mounting a directory entry of the LDAP directory system to a mount point of the UNIX filesystem in order to couple the Lightweight Directory Access Protocol directory system to the UNIX filesystem. Preferably, the directory system mounts beneath the mount point of the filesystem. Such mounting couples the directory system to the filesystem. Accordingly, a user of the apparatus can then navigate among the directory system in a manner similar to that for navigating around a filesystem (e.g., using xe2x80x9ccdxe2x80x9d to change current directories when navigating within a UNIX filesystem).
In one arrangement, the step of determining includes the step of ascertaining a location of the identified portion of the data storage system relative to the mount point. of the UNIX filesystem. This allows enables the controller to determine whether the identified portion of the data storage system is a file of the filesystem or a directory entry of the directory system. For example, if the identified portion of the data storage system resides below the mount point in an inverse-hierarchical arrangement between the UNIX filesystem (which includes the root, xe2x80x9c/xe2x80x9d) and the directory system, the identified portion is a directory entry of the directory system. However, if the identified portion is above the mount point, the identified portion is a file of the UNIX filesystem.
In an alternative arrangement, each file of the filesystem belongs to a file object class, and each directory entry of the directory system belongs to a directory entry object class. In this arrangement, the step of determining includes the step of deciding whether the identified portion belongs to the file object class or the directory entry object class. Accordingly, the controller can determine whether the identified portion is a UNIX file or LDAP directory entry.
In one arrangement, the access instruction is an open command, and the step of performing includes the step of carrying out, based on a result of the step of determining, one of a UNIX open operation and an LDAP open operation to open the identified portion of the data storage system.
In another arrangement, the access instruction is a create command, and the step of performing includes the step of carrying out, based on a result of the step of determining, one of a UNIX create operation and an LDAP create operation to create the identified portion of the data storage system.
In another arrangement, the access instruction is an unlink command, and the step of performing includes the step of carrying out, based on a result of the step of determining, one of a UNIX remove operation and an LDAP delete operation to erase the identified portion from the data storage system.
In another arrangement, the access instruction is a read command, and the step of performing includes the step of carrying out, based on a result of the step of determining, one of a UNIX read operation and an LDAP read operation to read data from the identified portion of the data storage system.
In another arrangement, the access instruction is a write command, and the step of performing includes the step of carrying out, based on a result of the step of determining, one of a UNIX write operation and an LDAP write operation to write data to the identified portion of the data storage system.
In another arrangement, the access instruction is a readdir command, and the step of performing includes the step of carrying out, based on a result of the step of determining, one of a UNIX readier operation and an LDAP readdir operation to obtain information regarding the identified portion of the data storage system (e.g., current location information when navigating around the data storage system).
Another arrangement of the invention is directed to a computer program product that includes a computer readable medium having instructions stored thereon for accessing a data storage system. The data storage system includes a filesystem and a directory system. The instructions, when carried out by the computer, cause the computer to perform the steps of: (a) obtaining an access instruction which identifies a portion of the data storage system; (b) determining, in response to the obtained access instruction, whether the identified portion of the data storage system is a file of the filesystem or a directory entry of the directory system; and (c) performing a file access operation to access the identified portion as a file when the identified portion is determined to be a file of the filesystem, and a directory entry access operation to access the identified portion as a directory entry when the identified portion is determined to be a directory entry of the directory system.
The directory system can be used as a repository for network information such as network configuration data and policy definitions. Application developers can then develop network applications which use an API having a file-like interface (i.e., file-like command names and expressions) to access the network information in entries of the directory system. In one arrangement, entries of the directory system are accessible using an interface of POSIX or POSIX-like names and expressions (e.g., open( ), read( ), write( ), etc.). Accordingly, in situations where the application developer knows a priori a location in the data storage system, an elaborate search filter is not required and the application developer can use familiar file-like system calls (e.g., open( ), read( ), write( ), etc.) to access the network information. The features of the invention, as described above, may be employed in data communications devices and other computerized devices such as those manufactured by Cisco Systems, Inc. of San Jose, Calif.